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IP Security Policy (IPSP) Requirements 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2003). All Rights Reserved. 
Abstract 


This document describes the problem space and solution requirements 
for developing an IP Security Policy (IPSP) configuration and 
management framework. The IPSP architecture provides a scalable, 
decentralized framework for managing, discovering and negotiating the 
host and network security policies that govern access, authorization, 
authentication, confidentiality, data integrity, and other IP 
Security properties. This document highlights such architectural 
components and presents their functional requirements. 
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1. Introduction 

1.1. Terminology 
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC 2119]. 


1.2. Security Policy and IPsec 


Network-layer security now enjoys broad popularity as a tool for 


protecting Internet traffic and resources. Security at the network 
layer can be used as a tool for at least two kinds of security 
architecture: 

a) Security gateways. Security gateways (including "firewalls") at 


the edges of networks use IPsec [RFC-2401] to enforce access 
control, protect the confidentiality and authenticity of network 
traffic entering and leaving a network, and to provide gateway 
services for virtual private networks (VPNs). 


b) Secure end-to-end communication. Hosts use IPsec to implement 
host-level access control, to protect the confidentiality and 
authenticity of network traffic exchanged with the peer hosts with 
which they communicate, and to join virtual private networks. 


On one hand, IPsec provides an excellent basis for a very wide range 
of protection schemes; on the other hand, this wide range of 
applications for IPsec creates complex management tasks that become 
especially difficult as networks scale up and require different 
security policies, and are controlled by different entities, for 
different kinds of traffic in different parts of the network. 
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As organizations deploy security gateways, the Internet divides into 
heterogeneous regions that enforce different access and security 


policies. Yet it is often still necessary for hosts to communicate 
across the network boundaries controlled by several different 
policies. The wide range of choices of cryptographic parameters (at 


multiple protocol layers) complicates matters and introduces the need 
for hosts and security gateways to identify and negotiate a set of 
security parameters that meets each party’s requirements. Even more 
complexity arises as IPsec becomes the means through which firewalls 
enforce access control and VPN membership; two IPsec endpoints that 
want to establish a security association must identify, not only the 
mutually acceptable cryptographic parameters, but also exactly what 
kind of access the combined security policy provides. 


While the negotiation of cryptographic and other security parameters 
for IPsec security associations (SAs) is supported by key management 
protocols (e.g., ISAKMP [RFC-2408]), the IPsec key management layer 
does not provide a scheme for managing, negotiating, or enforcing the 
security policies under which SAs operate. 


IPSP provides the framework for managing IPsec security policy, 
negotiating security association (SA) parameters between IPsec 
endpoints, and distributing authorization and policy information 
among hosts that require the ability to communicate via IPsec. 


2. The IP Security Policy Problem Space 


IPSP aims to provide a scalable, decentralized framework for 
managing, discovering and negotiating the host and network IPsec 
policies that govern access, authorization, cryptographic mechanisms, 
confidentiality, data integrity, and other IPsec properties. 


The central problem solved by IPSP is that of controlling security 
policy in a manner that is useful for the wide range of IPsec 
applications and modes of operation. In particular: 


- IPSP hosts may serve as IPsec endpoints, security gateways, 
network management hubs, or a combination of these functions. 
IPSP will manage end-users computers (which may be fixed 
workstations controlled by a single organization or mobile 
laptops that require remote access to a corporate VPN), 
firewalls (which provide different services and allow different 
levels of access to different classes of traffic and users), 
VPN routers (which support links to other VPNs that might be 
controlled by a different organization’s network policy), web 
and other servers (which might provide different services 
depending on where a client request came from), and so on. 
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- IPSP administration will be inherently heterogeneous and 
decentralized. A basic feature of IPsec is that two hosts can 
establish a Security Association even though they might not 
share a common security policy, or, indeed, trust one another 
at all. This property of IPsec becomes even more pronounced at 
the higher level abstraction managed by IPSP. 


-— The SA parameters acceptable to any pair of hosts (operating 
under different policies) will often not be specified in 
advance. IPSP will often have to negotiate and discover the 
mutually-acceptable SA parameters on-the-fly when two hosts 
attempt to create a new SA. 


- Some hosts will be governed by policies that are not directly 
specified in the IPSP language. For example, a host’s IPsec 
policy might be derived from a more comprehensive higher-layer 
security policy managed by some other system. Similarly, some 
vendors might develop specialized (and proprietary) tools for 
managing policy in their products. In such cases, it is 
necessary to derive an IPSP policy specification for only those 
aspects of a host’s policy that involve interoperability with 
other hosts running IPSP. 


- IPSP must scale to support complex policy administration 


schemes. In even modest-size networks, one administrator must 
often control policy remotely, and must have the ability to 
change the policy on many different hosts at the same time. In 


larger networks (or those belonging to large organizations), a 
host’s policy might be governed by several different 
authorities (e.g., several different departments might have the 
authority to add users to a firewall or open access to new 
services). Different parts of a policy might be "owned" by 
different entities in a complex hierarchy. IPSP must provide a 
mechanism for delegating specific kinds of authority to 
specific entities. 


- The semantics of IPSP must be well defined, particularly with 
respect to any security-critical aspects of the system. 


- IPSP must be secure, sound, and comprehensible. It should be 
possible to understand what an IPSP policy does; the difficulty 
of understanding an IPSP policy should be somewhat proportional 
to the complexity of the problem it solves. It should also be 
possible to have confidence that an IPSP policy does what it 
claims, and that IPSP implementation is correct; 
architecturally, the security-critical parts of IPSP should be 
small and well-specified enough to allow verification of their 
correct operation. Ideally, IPSP should be compatible with 
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formal methods, such as implementing security policies with 
provable properties. 


3. Requirements for an IP Security Policy Configuration and 
Management Framework 


3.1. General Requirements 
An IPSP solution MUST include: 


- A policy model with well-defined semantics that captures the 
relationship between IPsec SAs and higher-level security 
policies, 


- A gateway discovery mechanism that allows hosts to discover 
where to direct IPsec traffic intended for a specific endpoint, 


- A well-specified language for describing host policies, 


- A means for distributing responsibility for different aspects 
of policy to different entities, 


- A mechanism for discovering the policy of a host, 


- A mechanism for resolving the specific IPsec parameters to be 
used between two hosts governed by different policies (and for 
determining whether any such parameters exist); and, 


- A well-specified mechanism for checking for compliance with a 
host’s policy when SAs are created. 


The mechanisms used in IPSP must not require any protocol 
modifications in any of the IPsec standards (ESP [RFC-2406], AH, 
[RFC-2402], IKE [RFC-2409]). The mechanisms must be independent of 
the SA-negotiation protocol, but may assume certain functionality 
from such a protocol (this is to ensure that future SA-negotiation 
protocols are not incompatible with IPSP). 


3.2. Description and Justification 
3.2.1. Policy Model 


A Policy Model defines the semantics of IPsec policy. Policy 
specification, checking, and resolution should implement the 
semantics defined in the model. However, the model should be 
independent of the specific policy distribution mechanism and policy 
discovery scheme, to the extent possible. 
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3.2.2. Security Gateway Discovery 


The gateway discovery mechanism may be invoked by any host or 
gateway. Its goal is to determine what IPsec gateways exist between 
the initiator and the intended communication peer. The actual 
mechanism employed may be used to piggy-back information necessary by 
other components of the IPSP architecture (e.g., policy discovery, as 
is done in [SPP]). The discovery mechanism may have to be invoked at 
any time, independently of existing security associations or other 
communication, to detect topology changes. 


3.2.3. Policy Specification Language 


In order to allow for policy discovery, compliance checking, and 
resolution across a range of hosts, a common language is necessary in 
which to express the policies of hosts that need to communicate with 
one another. Statements in this language are the output of policy 
discovery, and provide the input to the policy resolution and 
compliance checking systems. Note that a host’s or network’s 
security policy may be expressed in a vendor-specific way, but would 
be translated to the common language when it is to be managed by the 
IPSP services. 


3.2.4. Distributed policy 


As discussed above, it must be possible for all or part of a host’s 
policy to be managed remotely, possibly by more than one entity. 
This is a basic requirement for large-scale networks and systems. 


3.2.5. Policy Discovery 


A policy discovery mechanism must provide the essential information 
that two IPsec endpoints can use to determine what kinds of SAs are 
possible between one another. This is especially important for hosts 
that are not controlled by the same entity, and that might not 
initially share any common information about one another. Note that 
a host need not reveal its entire security policy, only enough 
information to support the SA resolution system for hosts that might 
want to communicate with it. 


3.2.6. Security Association Resolution 
Once two hosts have learned enough about each other’s policies, it 
must be possible (and computationally feasible) to find an acceptable 


set of SA parameters that meets both host’s requirements and will 
lead to the successful creation of a new SA. 
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3.2.7. Compliance Checking 


When a host proposes the output of the SA resolution scheme, it must 
be checked for compliance with the local security policy of each 
host. The security and soundness of the SAs created by IPSP-managed 
communication should depend only on the correctness of the compliance 
checking stage. In particular, even if the SA resolution scheme 
(which is likely to be computationally and conceptually complex) 
produces an incorrect result, it should still not be possible to 
violate the specified policy of either host. 


4. Security Considerations 


This document discusses the high-level requirements for a policy 
framework and architecture for IPsec. A justification for the 
various components is given. 


5. IANA Considerations 
No action is required by IANA. 
6. Intellectual Property Statement 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 
has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. 


Copies of claims of rights made available for publication and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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11. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assignees. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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